Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

chore(deps): update node.js to v22 #92

Merged
merged 1 commit into from
Dec 5, 2024
Merged

chore(deps): update node.js to v22 #92

merged 1 commit into from
Dec 5, 2024
+10 −10

Conversation

open-turo-bot
Copy link
Contributor

@open-turo-bot open-turo-bot commented Oct 29, 2024 •
edited
Loading

This PR contains the following updates:

Package Type Update Change
node (source) major 20.18.1 -> 22.12.0
@types/node (source) devDependencies major 20.16.3 -> 22.10.1

Release Notes

nodejs/node (node)

v22.12.0: 2024-12-03, Version 22.12.0 'Jod' (LTS), @​ruyadorno

Compare Source

Notable Changes
require(esm) is now enabled by default

Support for loading native ES modules using require() had been available on v20.x and v22.x under the command line flag --experimental-require-module, and available by default on v23.x. In this release, it is now no longer behind a flag on v22.x.

This feature is still experimental, and we are looking for user feedback to make more final tweaks before fully stabilizing it. For this reason, on v22.x, when the Node.js instance encounters a native ES module in require() for the first time, it will emit an experimental warning unless require() comes from a path that contains node_modules. If there happens to be any regressions caused by this feature, users can report it to the Node.js issue tracker. Meanwhile this feature can also be disabled using --no-experimental-require-module as a workaround.

With this feature enabled, Node.js will no longer throw ERR_REQUIRE_ESM if require() is used to load a ES module. It can, however, throw ERR_REQUIRE_ASYNC_MODULE if the ES module being loaded or its dependencies contain top-level await. When the ES module is loaded successfully by require(), the returned object will either be a ES module namespace object similar to what's returned by import(), or what gets exported as "module.exports" in the ES module.

Users can check process.features.require_module to see whether require(esm) is enabled in the current Node.js instance. For packages, the "module-sync" exports condition can be used as a way to detect require(esm) support in the current Node.js instance and allow both require() and import to load the same native ES module. See the documentation for more details about this feature.

Contributed by Joyee Cheung in #​55085

Added resizable ArrayBuffer support in Buffer

When a Buffer is created using a resizable ArrayBuffer, the Buffer length will now correctly change as the underlying ArrayBuffer size is changed.

const ab = new ArrayBuffer(10, { maxByteLength: 20 });
const buffer = Buffer.from(ab);
console.log(buffer.byteLength); 10
ab.resize(15);
console.log(buffer.byteLength); 15
ab.resize(5);
console.log(buffer.byteLength); 5

Contributed by James Snell in #​55377

Update root certificates to NSS 3.104

This is the version of NSS that shipped in Firefox 131.0 on 2024-10-01.

Certificates added:

  • FIRMAPROFESIONAL CA ROOT-A WEB
  • TWCA CYBER Root CA
  • SecureSign Root CA12
  • SecureSign Root CA14
  • SecureSign Root CA15

Contributed by Richard Lau in #​55681

Other Notable Changes
  • [4920869935] - (SEMVER-MINOR) assert: make assertion_error use Myers diff algorithm (Giovanni Bucci) #​54862
  • [ccffd3b819] - doc: enforce strict policy to semver-major releases (Rafael Gonzaga) #​55732
  • [acc6806900] - doc: add jazelly to collaborators (Jason Zhang) #​55531
  • [88d91e8bc2] - esm: mark import attributes and JSON module as stable (Nicolò Ribaudo) #​55333
  • [98bfc7dce5] - (SEMVER-MINOR) http: add diagnostic channel http.client.request.created (Marco Ippolito) #​55586
  • [337f61fb25] - (SEMVER-MINOR) lib: add UV_UDP_REUSEPORT for udp (theanarkh) #​55403
  • [1628c48ad6] - (SEMVER-MINOR) net: add UV_TCP_REUSEPORT for tcp (theanarkh) #​55408
  • [457e73f4c9] - (SEMVER-MINOR) sqlite: add support for SQLite Session Extension (Bart Louwers) #​54181
Commits

v22.11.0: 2024-10-29, Version 22.11.0 'Jod' (LTS), @​richardlau

Compare Source

Notable Changes

This release marks the transition of Node.js 22.x into Long Term Support (LTS)
with the codename 'Jod'. The 22.x release line now moves into "Active LTS"
and will remain so until October 2025. After that time, it will move into
"Maintenance" until end of life in April 2027.

Other than updating metadata, such as the process.release object, to reflect
that the release is LTS, no further changes from Node.js 22.10.0 are included.

OpenSSL 3.x

Official binaries for Node.js 22.x currently include OpenSSL 3.0.x (more
specifically, the quictls OpenSSL fork).
OpenSSL 3.0.x is the currently designated long term support version that is
scheduled to be supported until 7th September 2026, which is within the expected
lifetime of Node.js 22.x. We are expecting upstream OpenSSL to announce a
successor long term support version prior to that date and since OpenSSL now
follows a semantic versioning-like versioning scheme we expect to be able to
update to the next long term supported version of OpenSSL during the lifetime of
Node.js 22.x.

v22.10.0: 2024-10-16, Version 22.10.0 (Current), @​aduh95

Compare Source

Notable Changes
New "module-sync" exports condition

This release introduces a "module-sync" exports condition that's enabled when
require(esm) is enabled, so packages can supply a synchronous ES module to the
Node.js module loader, no matter if it's being required or imported. This is
similar to the "module" condition that bundlers have been using to support
require(esm) in Node.js, and allows dual-package authors to opt into ESM-first
only on newer versions of Node.js that supports require(esm) to avoid the
dual-package hazard.

{
  "type": "module",
  "exports": {
    "node": {
      // On new version of Node.js, both require() and import get
      // the ESM version
      "module-sync": "./index.js",
      // On older version of Node.js, where "module-sync" and require(esm) are
      // not supported, use the CJS version to avoid dual-package hazard.
      // When package authors think it's time to drop support for older versions of
      // Node.js, they can remove the exports conditions and just use "main": "index.js".
      "default": "./dist/index.cjs"
    },
    // On any other environment, use the ESM version.
    "default": "./index.js"
  }
}

Or if the package is only meant to be run on Node.js and wants to fallback to
CJS on older versions that don't have require(esm):

{
  "type": "module",
  "exports": {
    // On new version of Node.js, both require() and import get the ESM version
    "module-sync": "./index.js",
    // On older version of Node.js, where "module-sync" and require(esm) are
    // not supported, use the CJS version to avoid dual-package hazard.
    // When package authors think it's time to drop support for older versions of
    // Node.js, they can remove the exports conditions and just use "main": "index.js".
    "default": "./dist/index.cjs"
  }
}

For package authors: this only serves as a feature-detection mechanism for
packages that wish to support both CJS and ESM users during the period when some
active Node.js LTS versions support require(esm) while some older ones don't.
When all active Node.js LTS lines support require(esm), packages can simplify
their distributions by bumping the major version, dropping their CJS exports,
and removing the module-sync exports condition (with only main or default
targetting the ESM exports). If the package needs to support both bundlers and
being run unbundled on Node.js during the transition period, use both
module-sync and module and point them to the same ESM file. If the package
already doesn't want to support older versions of Node.js that doesn't support
require(esm), don't use this export condition.

For bundlers/tools: they should avoid implementing this stop-gap condition.
Most existing bundlers implement the de-facto bundler standard
module
exports condition, and that should be enough to support users who want to bundle
ESM from CJS consumers. Users who want both bundlers and Node.js to recognize
the ESM exports can use both module/module-sync conditions during the
transition period, and can drop module-sync+module when they no longer need
to support older versions of Node.js. If tools do want to support this
condition, it's recommended to make the resolution rules in the graph pointed by
this condition match the Node.js native ESM rules to avoid divergence.

We ended up implementing a condition with a different name instead of reusi

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about these updates again.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

@open-turo-bot open-turo-bot requested a review from a team as a code owner October 29, 2024 00:09
@coveralls
Copy link

coveralls commented Oct 29, 2024 •
edited
Loading

Pull Request Test Coverage Report for Build 12150365677

Details

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 89.189%
Totals Coverage Status
Change from base Build 12076826937: 0.0%
Covered Lines: 46
Relevant Lines: 49
💛 - Coveralls

@open-turo-bot open-turo-bot changed the title chore(deps): update dependency @types/node to v22 chore(deps): update dependency node to v22 Oct 30, 2024
@open-turo-bot open-turo-bot force-pushed the c/renovate_node-22.x branch 3 times, most recently from eef968e to ae9f926 Compare November 6, 2024 00:09
@open-turo-bot open-turo-bot changed the title chore(deps): update dependency node to v22 chore(deps): update node.js to v22 Nov 13, 2024
@open-turo-bot open-turo-bot force-pushed the c/renovate_node-22.x branch 4 times, most recently from a29acc8 to 07af5f7 Compare November 26, 2024 00:09
@open-turo-bot open-turo-bot force-pushed the c/renovate_node-22.x branch 2 times, most recently from 523ca11 to 280f9bb Compare November 29, 2024 00:09
@github-actions GitHub Actions
Copy link

github-actions bot commented Dec 4, 2024

Release notes preview

No new release will be created.

If you are expecting a release, you will need to either fix a bug or add a feature.
Chores, CI, docs, refactoring, style and other changes will not trigger a release.

@tagoro9 tagoro9 merged commit d047c99 into main Dec 5, 2024
4 checks passed
@tagoro9 tagoro9 deleted the c/renovate_node-22.x branch December 5, 2024 16:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@tagoro9 tagoro9 tagoro9 approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@open-turo-bot @coveralls @tagoro9 @renovate-bot